Tested #21 against a clone of a real 1.4M-node graph before merge — green light from our side. 👍

We snapshotted a live context-intelligence graph (1,398,163 nodes / 1,937,529 rels) into a throwaway Neo4j and ran the migration there. Production was never touched.

Tests (independent run):

• tests/neo4j/ -m neo4j → 69 passed
• unit (-m "not neo4j and not integration") → 1326 passed
• ruff clean

ensure_neo4j_schema on the real graph:

So: ~10s end-to-end at real scale, no OOM, no errors. The dead-code backfill now runs and completes, and the drop-legacy-index → create-:Node-constraint handoff lands cleanly (no window where the graph is left without a backing index).

One non-blocking suggestion: the Step-1 global dedup (MATCH (n) WITH ... collect(n) ... DETACH DELETE) is the only un-batched pass in the migration. It was fine here — our graph had exactly 1 duplicate, so the collect groups are trivial — but it materializes a group-map over all nodes in heap. We tested on a large (ergonomic) JVM heap, so we can't certify it's OOM-proof on a memory-constrained Neo4j. Worth wrapping in CALL { ... } IN TRANSACTIONS like the backfill right below it — cheap insurance against the exact unbounded-transaction shape that motivated the chunking work originally.

Net: safe to merge from a real-data-scale standpoint. The self-healing edge writer + backfill resurrection both check out. Nice work.

Thanks for running it against a real 1.4M-node clone, @bkrabach — that's the validation that matters here.

On the Step-1 dedup batching suggestion: I tried it two ways and both made things worse on a memory-constrained Neo4j, so I'm keeping the un-batched form. Evidence:

• Wrapping the DETACH DELETE in CALL { … } IN TRANSACTIONS — both the original collect(n) form and a lighter scalar-count(*) driving form — trips the 2 MiB db.memory.transaction.max integration test (tests/neo4j/test_orphan_visibility.py::test_finalization_orphan_surfaces_on_status) with MemoryPoolOutOfMemoryError.
• Root cause: CALL { … } IN TRANSACTIONS eagerly materializes its driving rows before the first inner batch, and the dedup needs a grouping aggregation to find duplicate (node_id, workspace) keys — so peak memory goes up on a constrained heap, not down. The :Node backfill can use IN TRANSACTIONS safely only because its driving query is a plain streaming MATCH (n) WHERE NOT n:Node with no aggregation buffer.
• The un-batched dedup passes that exact 2 MiB-capped test (and the full tests/neo4j suite, 69 passed) in addition to your 1.4M-node run — i.e. it's the form that actually survives the memory-constrained scenario the suggestion was guarding against.

If we ever need hard bounding for a pathologically duplicated graph, the right shape is a streaming per-key delete that avoids any full-graph grouping — but that wants the :Node index in place first, so it's a post-migration follow-up rather than something to fold into this pass. For the data we have (your clone had a single duplicate group), the un-batched dedup is correct and bounded enough. Leaving it as-is.